Requirements for software projects and resulting products, such as an application maintenance or development project, often change, from those included in an initial project request (IPR), during the software development life cycle. For example, a requester of software development services may decide the required software product should be modified to include or exclude functionality, for example, as typically set forth in a project change request (PCR) including the associated attributes.
Current methods of assessing impact to quality and risks, as well as predicting defects, of accepting a PCR are unreliable and ineffective, time-consuming, uninformative, and inadequate. Such methods generally include project managers or teams relying on their experience and confidence, for example, as qualitative parameters used to decide whether to accept a PCR.
Unfortunately, such qualitative parameters do not provide an effective measure of overall impact to quality of implementing a PCR and do not provide insight regarding where in the software development life cycle, for example, the software may be exposed to increased risk so that a developer can take proactive measures or mitigate such risks. Moreover, resulting communications to the requester of the software regarding the PCR often do not adequately set expectations regarding risks and impact to quality of implementing the PCR and, further, such communications lacking quantitative analysis and based on qualitative indicators are often ignored.